View AN1077_8288358.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

AN1077/0201 1/14 AN1077 application note overview of enhanced can controllers for st7 and st9 mcus by microcontroller division applications abstract automotive body network requirements have changed significantly in the last few years due to the introduction of osek and the increasing number of ecus. 8-bit microcontrollers are and will stay widely used in a majority of automotive body applica- tions. while a wide variety of powerful can controllers are available on the market for 16- and 32-bit microcontrollers, 8-bit microcontrollers still need too much cpu time for can communi- cation management. this application note presents a new generation of can controllers opti- mized for 8-bit microcontrollers and designed to meet the needs of body applications. 1
2/14 overview of enhanced can controllers for st7 and st9 mcus 1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 evolution of automotive networks . . . . . . . . . . . . . . . . . . . . . 3 1.2 impact on can traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 impact on can controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 can controller solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 trade-off between costs and efficiency . . . . . . . . . . . . . . . . 5 3 bxcan and becan: the new can solutions . . . . . . . . . . . . . . . . . . . . 6 3.1 bxcan main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 can core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 transmission handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 message filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 reception handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6 becan main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4 validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2
3/14 overview of enhanced can controllers for st7 and st9 mcus 1 introduction 1.1 evolution of automotive networks for several years can has been the world wide standard automotive communication protocol. well established in power train applications in its high speed version, can is now used to con- nect a high number of ecus in each car body. this body network - known as low speed can - brought major changes with its introduction. standardized higher layer today automotive manufacturers and their suppliers are going one step further towards stand- ardization, integrating the osek software modules on each ecu. hierarchical architectures to master the complexity caused by the increasing number of ecus in car bodies, several networks and sub-networks are required. this limits the number of nodes connected to one network, but requires more nodes with a simple gateway function. low-end communication protocol local sub-networks - e.g. within one door module - does not need the full multi- master capa- bilities, speed and robustness of can. for this purpose the lin communication protocol has been introduced as a low-cost solution.
4/14 overview of enhanced can controllers for st7 and st9 mcus 1.2 impact on can traffic these changes have an impact in terms of can message traffic. application messages even if the information transmitted by each ecu has not increased significantly, the growing number of ecus in body applications has led to a drastic increase in can traffic. sometimes the same ecu may be used in several locations in the car - for instance for the right and for the left door module C so a node must be able to handle more message identifiers than the ap- plication itself would really require. a similar effect occurs when the same ecu is planned to be implemented in different car models or versions, this means the number of identifiers the node has to handle will increase. network management messages in addition to the application messages, management messages like osek network manage- ment are needed to configure the network at start-up time, to control the bus when the nodes enter and exit sleep mode, to monitor the node while running and to handle bus-off conditions. this distributed nm requires the implementation of the osek-nm software on each ecu, which has to monitor the nm messages of all the other nodes. this nm is based on the token ring method and each node has its own address. the source and destination addresses are coded in the identifier of the can message. this means that there are as many identifiers needed for the nm as nodes in the network. diagnosis messages for diagnosis purposes each ecu must be accessible to external diag- nosis tools. according to iso 15765-1 and 2 these diagnosis services are now implemented via can. these services require their own can messages. 1.3 impact on can controllers just as the introduction of networks has modified automotive application implementations in a major way, modern network architectures have also changed the requirements imposed on can controllers. as mentioned earlier, the resource requirements have increased especially on the receiver side: n a huge number of identifiers on the bus n a high number of identifiers to be handled n various types of messages all quiet in the 8-bit can world? while many can controllers for 16- and 32-bit microcontrollers have been recently developed in order to satisfy these new requirements, most of the can controllers implemented on 8-bit microcontrollers do not provide the required hardware to support these new functions effi-
5/14 overview of enhanced can controllers for st7 and st9 mcus ciently. therefore software solutions are usually implemented, consuming cpu resources and making the application less independent from the can bus traffic. the overall tasks of the can interface considering the receiver part of the can interface the following tasks have to be performed: n message checking, error handling and acknowledgement. this task is fully handled by the can protocol implemented in all can controllers n message filtering indicates receptions addressed to the application and discards the other ones. this task is partially done by hardware but software filtering is often needed. the cpu resources consumed for software filtering depends on the can bus traffic. this means that the ecu performance is influenced by events not related to the application. this can make the modification of an entire system or the integration of the ecu in another network very critical. n identifier recognition. once a message has passed through the filters its content must be identified in order to compute the destination address the data must be stored to. n signal extraction. to optimize the bandwidth usage of the can bus, the signals are concatenated to have more data transmitted in each message. thus on message reception the application must extract the signals it is interested in. n signal storage in ram 2 can controller solutions 2.1 trade-off between costs and efficiency nowadays can controllers can be classified in two main families: n basiccan this approach provides only few mailboxes for message transmission and reception. this so- lution allows very compact implementations on silicon. advantages: C very cost-effective and therefore well suited to 8-bit microcontrollers drawbacks: C requires cpu resources for filtering, identifier recognition and signal storage C high software real-time constraints on message reception n fullcan this approach provides more mailboxes than messages to handle. in the past, 16 mailboxes were sufficient, today 32 or 64 are standard. advantages: n autonomous message filtering n one static identifier per mailbox
6/14 overview of enhanced can controllers for st7 and st9 mcus drawbacks: n 16 mailboxes are not sufficient for body applications n 32 mailboxes to expensive for 8-bit microcontrollers n static usage of mailboxes not efficient in body application. 3 bxcan and becan: the new can solutions as mentioned previously for cost efficiency reasons, an 8-bit microcontroller cannot afford to have a huge fullcan controller with 32 mailboxes. therefore sts new solutions are based on a basiccan architecture, which has been extended to meet body application requirements. 3.1 bxcan main features the basic extended can - called bxcan - supports: n can protocol version 2.0 a, b active n bit rates up to 1mbit/s at 8mhz n three transmit mailboxes n priority by identifier or fifos n two receive fifo with three stages each n eight scalable filters C can be associated with fifo 0 or 1 C identifier list feature C filter match index 3.2 can core although the can core is the heart of any can controller, this is also the most common part. this means that all can cores have to be compliant with the can standard and from an ap- plication point of view do not differ from each other. the processor interface providing the mailboxes, filters etc. must meet the application requirements and can evolve accordingly. for this reason the bxcan is based on the bosch can core of the c_can product.
7/14 overview of enhanced can controllers for st7 and st9 mcus figure 1. figure 1: bxcan block diagram 3.3 transmission handling three transmit mailboxes are provided to the application to set-up messages for transmission. three mailboxes reduce software queuing and allow deterministic transmission. the trans- mission scheduler decides which mailbox has to be transmitted first according to the priority rules. transmit priority rules bxcan provides two modes for the transmit priority: n in identifier mode when more than one transmit mailbox are pending, the identifier of the message stored in the mailbox gives the transmission order. the message with the lowest identifier value has the highest priority according to the arbitration of the can protocol. n in fifo mode the priority order is given by the transmit request order. this mode is well suited for segmented transmission. mailbox 2 mailbox 1 7 6 5 can 2.0b active core mailbox 0 transmission acceptance filters tx mailboxes master control scheduler master status transmit control transmit status transmit priority receive fifo error status error int. enable tx error counter rx error counter diagnostic bit timing filter mode filter config. page select interrupt enable mailbox 0 1 2 receive fifo 1 4 3 2 1 filter 0 mailbox 0 1 2 receive fifo 0 control/status/configuration
8/14 overview of enhanced can controllers for st7 and st9 mcus 3.4 message filtering figure 2. filter scale and configuration one of the bxcans key improvements is the extended filter mechanism avoiding any mes- sage filtering by software. this pure hardware filtering makes the cpu performance inde- pendent from the can bus traffic. hardware filtering: n saves cpu resources required for software filtering one 32-bit filter two 16-bit filters one 16-bit / two 8-bit filters four 8-bit filters cfxr0 cfxr4 cfxr1 cfxr5 cfxr2 cfxr6 cfxr3 cfxr7 cfxr0 cfxr2 cfxr1 cfxr3 cfxr4 cfxr6 cfxr5 cfxr7 cfxr0 cfxr2 cfxr1 cfxr3 cfxr4 cfxr5 cfxr6 cfxr7 cfxr0 cfxr1 cfxr2 cfxr3 cfxr4 cfxr5 cfxr6 cfxr7 x = filter number fscx = 3 fscx = 2 fscx = 1 fscx = 0 filter scale configuration 1 these bits are located in the cfcr register s filter scale config. bits 1 identifier mask/ident. identifier mask/ident. identifier mask/ident. identifier mask/ident. identifier mask/ident. identifier mask/ident. identifier mask/ident. identifier mask/ident. identifier mask/ident. stid10:3 stid2:0 rtr ide exid17:15 exid14:7 exid6:0 bit mapping stid10:3 bit mapping stid10:3 stid2:0 rtr ide exid17:15 identifier mask/ident. bit mapping
9/14 overview of enhanced can controllers for st7 and st9 mcus n eases the software development evaluation, as even if the can bus traffic is not well defined at the beginning of the project, changes will not impact the cpu behaviour n eases the integration of this ecu in a new system to fulfil this requirement the bxcan controller provides eight configurable and scalable filters to the application, in order to receive only the messages the application needs. scalable width to optimise and adapt the filters to the application needs, each filter can be scaled independ- ently. the following combinations are possible: n one 32 bit filter for filtering the stdid[10:0], ide, extid[17:0] and rtr bits. n two16 bit filters for filtering the stdid[10:0], rtr and ide bits. n four 8 bit filters for filtering the stdid[10:3] bits. the other bits are considered as dont care. n one 16 bit filter and two 8 bit filters. furthermore each filter can be configured in mask mode or in identifier list mode. mask mode in mask mode the identifier registers are associated with mask registers specifying which bits of the identifier are handled as must match or as dont care. this mode is well suited for se- lecting a group of identifiers, for instance network management messages. identifier list mode in identifier list mode the mask registers are used as identifier registers. thus, instead of de- fining an identifier and a mask, two identifiers are specified, doubling the number of config- urable single identifiers. all bits of the incoming identifier must match with the bits specified in the filter registers. this mode is well suited for application messages as their identifiers are quite randomly distributed. filter configuration while the scale and mode configuration must be done during the initialization of bxcan, the value of the identifiers and masks registers can be modified on the fly.
10/14 overview of enhanced can controllers for st7 and st9 mcus 3.5 reception handling figure 3. message filtering and storage for the reception of can messages bxcan provides two fifos. each fifo can store 3 com- plete can messages without cpu intervention. each filter can be independently associated with fifo 0 or fifo 1. this structure reduces the real-time constraint on message reception on the application side. in order to reduce cpu load, simplify the software and guarantee data consistency, the fifo is managed completely by hardware. the application accesses the messages stored in the fifo through the fifo output mailbox. message prioritization a drawback of the fifo architecture is that at reception time the application does not know the level of priority of these messages. thus all messages have to be handled with the same ur- gency. to address this issue bxcan provides two independent fifos. this allows differenti- identifier list message discarded identifier & mask identifier 0 identifier 1 identifier 2 identifier n identifier n+1 mask identifier n+m mask identifier message received ctrl data identifier #2 match message stored receive fifo no match found n: number of single identifiers to receive m: number of identifier groups to receive n and m values depend on the configuration of the filters
11/14 overview of enhanced can controllers for st7 and st9 mcus ated handling for high priority messages and non-critical messages. this feature helps to re- duce the real-time constraint on the application. filter match index once a message has been stored in the fifo, the application will transfer the data to the ram. bxcan provides a filter match index, fmi, corresponding to the index of the filter the message passed through. the fmi is stored in the fifo with the received message. because of their wide spread distribution, can identifiers cannot be immediately used as an index to the destination location of the data. the fmi provides a means of accessing a receive mes- sage table directly. valid message a message is considered as valid when it has been received without error until the last but one bit of the eof field. and it passes through the identifier filtering successfully. fifo overrun the can core has its own message buffer and starts transferring the message to the fifo once the message is considered as valid. thus an overrun condition will occur if four valid messages have been received in the same fifo but not handled by the application. further- more this mailbox in the can core guarantees that no erroneous message will overwrite a cor- rect one already stored in the fifo. 3.6 becan main features the basic enhanced can - called becan - supports: n can protocol version 2.0 a, b active n bit rates up to 1mbit/s at 8mhz n two transmit mailboxes C priority by identifier or fifo n one receive fifo with three stages n four scalable filters C identifier list feature C filter match index
12/14 overview of enhanced can controllers for st7 and st9 mcus figure 4. figure 4: becan block diagram the becan is based on the same fifo and filter concept as bxcan but targets applications requiring less communication resources. this leads to a reduced processor interface function- ality. 4 validation bxcan and becan are based on the can core of boschs c_can controller. this approach limits the development risk, reusing the huge experience bosch has gained during more than one decade of can controller development. to guarantee the compliance of the boschs can core with the can standard, the c_can has been validated according to the iso standard 16845 ?can conformance testing. the validation has been performed by the c&s group led by prof. dr. w. lawrenz located in wolfenbttel, germany. for several years, c&s has been well accepted world wide as an organisation for can con- troller validation. can 2.0b active core mailbox 0 transmission filter 1 2 3 mailbox 1 mailbox 0 1 2 receive fifo acceptance filters tx mailboxes master control scheduler master status transmit status transmit prio receive fifo error status error int. enable tx error counter rx error counter diagnostic bit timing filter master filter config. page select interrupt enable 0 control/status/configuration
13/14 overview of enhanced can controllers for st7 and st9 mcus 5 conclusion these two new can controllers bxcan and becan have been designed to meet the require- ments of todays and tomorrows automotive body applications. in particular can message filtering (this cpu resources consuming and difficult to evaluate task) has been optimized by the implementation of the ?identifier list concept and the in- creased number of filters. freed from the filtering task, the cpu can completely focus on the application tasks. with eight filters and two independent receive fifos, bxcan can easily handle a high number and different types of well selected messages. this is an ideal can interface for decentralized gateways and all applications with high capacity communications requirements.
14/14 overview of enhanced can controllers for st7 and st9 mcus the present note which is for guidance only aims at providing customers with information regarding their products in order for them to save time. as a result, stmicroelectronics shall not be held liable for any direct, indirect or consequential damages with respect to any claims arising from the content of such a note and/or the use made by customers of the information contained herein in connexion with their products. information furnished is believed to be accurate and reliable. however, stmicroelectronics assumes no responsibility for the co nsequences of use of such information nor for any infringement of patents or other rights of third parties which may result from its use. no license is granted by implication or otherwise under any patent or patent rights of stmicroelectronics. specifications mentioned in this publicati on are subject to change without notice. this publication supersedes and replaces all information previously supplied. stmicroelectronics prod ucts are not authorized for use as critical components in life support devices or systems without the express written approval of stmicroele ctronics. the st logo is a registered trademark of stmicroelectronics ? 2001 stmicroelectronics - all rights reserved. purchase of i 2 c components by stmicroelectronics conveys a license under the philips i 2 c patent. rights to use these components in an i 2 c system is granted provided that the system conforms to the i 2 c standard specification as defined by philips. stmicroelectronics group of companies australia - brazil - china - finland - france - germany - hong kong - india - italy - japan - malaysia - malta - morocco - sin gapore - spain sweden - switzerland - united kingdom - u.s.a. http://www.st.com

▲Up To Search▲

Price & Availability of AN1077

	To Download AN1077 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .